The Atari Compendium

home *** CD-ROM | disk | FTP | other *** search

/ The Atari Compendium / The Atari Compendium (Toad Computers) (1994).iso / files / umich / diskutil / bfrd_10.zoo / bfrd.doc next >

Wrap

Text File | 1993-07-23 | 14.8 KB | 240 lines

************************************************************************** * * * BU_BFRD.PRG & RES_BFRD.PRG - (Version 1.0) * * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ * * * * BOOTSECTOR, FATS & ROOTDIRECTORY BACKUP & RESTORE UTILITIES * * * * ( upgrade to BFRDBU.PRG v_1.0, distributed as BFRDBU10.ZOO ) * * * * Author: W. Alan B. Evans, University of Kent, Canterbury, UK. * * * * (These Programs must NOT be sold commercially without the Author's * * Permission. FREE Distribution is allowed on condition that the * * the documentation File, BFRD.DOC, always accompanies the programs) * * * * ( WARNING!! These disk utility programs can seriously damage * * Disk Structures if used incorrectly. It is hereby understood * * that THESE PROGRAMS ARE USED ENTIRELY AT THE USER'S RISK, and * * the Author will in NO WAY be responsible for any such damage * * howsoever caused. wabe@ukc.ac.uk July 1993 ) * * * ************************************************************************** Preamble ~~~~~~~~ A few years ago, I had Hard Disk Troubles of the kind that led to the FATS and ROOTDIRECTORY info on my SH205 being frequently over-written. This of course results in making the files on that partition, though largely undamaged, virtually inaccessible. In an ideal world this should NEVER happen but imperfect hardware, software and/or human error not to mention human sabotage (malignant FAT-eating viruses!) can lead to this disastrous situation. As a cure, I initially wrote a Hard Disk backup program HDQBUR - "Hard Disk Quick Backup & Restore" which was distributed to the Archives in the past as part of HD_UTILS). This has since evolved to VTABU - "the Volume Transferor and Backer-Upper" (not distributed) which enables tha saved sector-copy of a partition to be restored to a differently (but adequately!) sized partition on (perhaps) a new Hard Disk. Whilst a "full" backup of this kind is fine, the fact is that it takes quite a long time and rather many disk swaps to even back-up a single, relatively-full 16 Mbyte partition that it tends not to get done very often. I eventually realised that what I really needed was an utility that simply copied the FATS and ROOTDIRECTORY Info on a selected Partition to file (stored on floppy or, perhaps, on another Partition). This of course is quick and can be done daily or even every time you boot up. Then if a subsequent disaster occurs this info can be restored and thus access is regained to the locations of ALL rootdirectory files (and directories) that have NOT been altered since the last backup - provided, of course, they are undamaged by the initial disaster!!. However new files you may have created or files that have been edited since the last backup will of course be lost or "uncomplete". But often this is not so bad as they tend to be fresh in your mind and are usually fairly easily redeemable from some other source (e.g. floppy copy etc.). After "restoring" such Partitions it is advisable to check its FATS' integrity with some suitable Utility such as ICD's "CLEANUP" (which I personally find excellent) or, maybe, with Jorge Lohse's FSCK.PRG (though this is old and works only on non-extended {<= 16 Mbyte} and non-BGM partitions) or with other more recent disk-tools that I've heard of but never tried. Most imperfect files can be "weeded-out" this way. Thus BFRDBU.PRG (already distributed to Atari Archive) came to be - and during the past few years, has saved me a great deal of trouble, alas on several occasions. The current offering, BU_BFRD.PRG & RES_BFRD.PRG, is an upgrade on that in the sense that in the tiny BACKUP_ONLY program, BU_BFRD.PRG, I have implemented the "quick" cyclic backing of all partitions on "other" partitions (see below) that I mentioned in the documentation (BFRDBU.DOC) that accompanied the earlier version and which, indeed, I first thought of when writing that DOC. This improvement reduced the total time to back-up ALL partitions on my 105 Mbyte Hard Disk to only 9 secs from the 65 secs or so it took to back them onto floppy. Of course, this program is ideal as an AUTO-folder back-up program (it uses no GEM). RES_BFRD.PRG is similar to BFRDBU.PRG in that it restores and back-ups, but now with the option of which directory to store the backup files ( instead of invariably in floppy drive A: ). It also has several other minor improvements. Like the earlier BFRDBU, RES_BFRD uses GEM only in its "restore" option, and so could in principle be used as an AUTO folder program for back-ups only. For instance, you would do this should you wish all your backup files to go to a single directory (e.g. A: ). Of course, these programs also serve as a protection against accidental "human" FAT corruption as well as FAT corruption due to faulty Hardware and/or Software. Such a situation could arise (as it did ONCE for me) when I wished to delete all files in a subdirectory and so (from GULAM) I typed " rm * ". Yes, you've guessed it - I had forgotten I'd just changed directory to the root D:\ and GULAM proceeded to delete ALL files in D:\ - or would have done had I not hit the warm reset button in panic. As it happened, I had a fairly recent FAT backup of D:\, and catastrophe was averted by restoring that - though I blush to admit that I spent about half an hour with a file UNDELETING tool ( Simon Poole's DLII.PRG) before it became apparent that this tool (as would all "undeleting" tools I think) was proving ineffective (as so many deleted files were fragmented) before the above-mentioned "obvious" solution hit me! BU_BFRD.PRG - The back-up program - suitable for AUTO folder use. ~~~~~~~~~~~ BU_BFRD will save the Bootsector-Fats-Rootdirectory Info on selected partitions (or Volumes) into .FBU (Fats Back-Up) files such as C_BFRD.FBU, .., E_BFRD.FBU that must be saved to "other" (i.e. distinct) Hard Disk Partitions. It would, of course, be silly to save C_BFRD.FBU to a file on drive C:\ since it could not be found if C:\'s FATS became corrupt!!. Saving to Hard Disk (as compared with saving to floppy) makes the backing up process extremely quick. As mentioned above I now regularly back-up all my C:\,D:\,E:\ and F:\ partitions on my ICD 105 Mbyte Hard disk in about 9 seconds when I boot up. So, to set-up, you must decide a suitable permutation of partitions onto which to write each partition's backup file. A viable permutation would be to save these .FBU files to different partitions cyclically - e.g. if you have Partitions C:\, D:\ and E:\, then save C_BFRD.FBU to D:\, D_BFRD.FBU to E:\ and E_BFRD.FBU to C:\. As currently configured you MUST save your LAST Hard Disk Partition onto drive C:\. If this is F:\ (say) then, to initialise things, you should copy a dummy file (any old file will do - it'll soon be deleted and replaced) to C:\ and name it F_BFRD.FBU. The first letter (F) of this filename tells BU_BFRD how many Hard Disk Partitions exist (nb. the presence of RAMDISKS could otherwise complicate matters if you were to try to determine this with the Drvmap() function). You must also copy dummy files to D:\, E:\ and F:\ and name them similarly - the first letter of each filename signifying which drive's ROOTDIRECTORY & FATS info is to be saved to these partitions. Personally I followed the cyclic permutation convention - so I named these to C_BFRD.FBU on D:\, D_BFRD.FBU on E:\ and E_BFRD.FBU on F:\ - but you could permute these names subject to the constraint that F_BFRD.FBU must remain on C:\. Having set these dummy files, run BU_BFRD.PRG and answer [y]es to the prompt, and your dummy files will be replaced by the proper FAT/ROOTDIRECTORY backups in about 10 seconds or less (assuming you have TOS >= 1.04 ; earlier TOSes had an inefficient File writing algorithm and filewriting takes longer). Then put BU_BFRD.PRG in your AUTO folder and, every time you boot, you will then have the choice to update your back-ups. Note both BU_BFRD and RES_BFRD do check on each partition's logical sector size so that they can safely be used with BGM Partitions etc. (I have been doing so for years!). RES_BFRD.PRG - The Restore (and, optionally, backup) program ~~~~~~~~~~~~ This program is the one to restore the FAT\ROOTDIRECTORY information should a disaster occur. It does also have the ability to backup partitions to a specified directory (e.g. A: or D:\BACKS etc. ) in the which case ALL your back-up files will go to this directory. Generally speaking, it is not wise to place these in a "vulnerable" hard disk partition except that so many hard disks now have "removable inserts" or "flopticals" if you like. In this sense, RES_BFRD.PRG is self-contained i.e. should really be called RESBU_BFRD.PRG (restore and back-up) - but I'm sure most will find BU_BFRD more convenient to back-up from the AUTO folder, and so I guess RES_BFRD's back-up option will be little used. The selection of drives (which could be Floppy drives or RAMDISKS as well as Hard Disk Partitions) to be backed is done simply by entering a string e.g. "CEF" (case or order does not matter) which is made up of the Drive Letters of all selected drives i.e. in this example you would be selecting Partitions C:\, E:\ and F:\ (note here you need not back up ALL partitions; nor, indeed, do you have to with BU_BFRD - for if there is no filename X_BFRD.FBU on any partition then drive X will not be backed). The BACKUP option of RES_BFRD does not use any GEM and so "could", if desired, be used as an AUTO-folder program at booting-up time. However, for the RESTORE option I thought it convenient to have some FormAlerts and the GEM FileSelector so that this (hopefully rarely needed) option must be done after boot-up within the GEM/AES environment. No elaborate explanations are needed here - RES_BFRD will prompt you with simple questions at each stage. Finally I should mention that RST_BFRD is packed with the (MINT compatible) ICE v_2.4 packer which reduces it from 10 to 6 kbytes or so. After a partition is restored I have NOT FORCED a reset (STMIROR2 for example forces a COLD reset - which of course would destroy any RAMDISKs you may have loaded). Instead, after a "restore", RES_BFRD displays an alert inviting you to do a WARM reset (preserves reset-survivable ramdisks) with the option of coming out without doing a reset at all. This is in recognition of the fact that there is software about today that can force TOS to update its buffer information on a selected drive e.g. Charles F. Johnson's excellent "Little Green Fileselector" LGSELECT will do this task if you click on a drive icon whilst pressing down either of the SHIFT keys. If I knew how this is done I'd code it in so that the question of a reset would not arise. My Mark Williams C Manual gives no info on how to force a media change ( so if anyone can tell me the trick ..... ). Anyway, if you are in doubt, THEN ALWAYS SELECT A WARM RESET AFTER A RESTORE or be sure to do one fairly soon after BEFORE ANY WRITES TO THE RESTORED PARTITION ARE MADE. It is possible to incur serious file damage if you write to a restored partition without updating TOS on the changes you've made (behind it's back). It seems to be (though I could be wrong here) that if you have not opened any subdirectories on the damaged partition prior to the "restore", then you are fairly safe - but DON'T TAKE MY WORD ON THIS - IF THE CONTENTS ARE IMPORTANT - PLAY SAFE AND DO A WARM RESET. SOME HISTORY ~~~~~~~~~~~~ I recently discovered, that this useful idea of saving the FAT and ROOTDIRECTORY Info - which I implemented in about 1989, was also independently implemented at about that time (or earlier) by Michael J. Mitchell of Catspaw Software Systems in the release of his STMIRROR program. I downloaded STMIROR2.PRG (Version 2 of this) from a.a. a few days ago (July 20th 1993) and discovered it does much the same task as RES_BFRD detailed above. STMIROR2 is a very elegant, user-friendly GEM Program with an elaborate Menu. Unfortunately, this very elegance means it cannot be used from the AUTO folder. Further, it has to be used repeatedly to save info on multiple partitions. The same idea also is one of the "most hailed" features of the recent (and, by all accounts, quite comprehensive) commercial Disk Utility Program "Diamond Edge" developed by Bob Luneski et al of Oregon Research (the UK importers are Hisoft). If what I infer from reading an article about it in "ST Applications" is correct, I think "Diamond Edge" (in its "Mirror-backup" option) is very similar to STMIROR2 and BU_BFRD (except I think it stores all the info in one predetermined directory) and appears to go one step further than either BU_BFRD or STMIROR2 in that it will also save info recursively on all the subdirectories ( but as I've no personal experience of Diamond Edge cannot be certain of this). Of course, this will take that much longer time but still, by all accounts, is fast enough not to deter one from backing up daily. I had for a long time toyed with adding this feature but, as it involved quite a lot of additional coding, increases the backing-up time, and also since I've never, personally, experienced or heard of an accident where BOTH subdirectory AND rootdirectory contents were simultaneously damaged but with virtually all the files intact, I never did get down to doing it. Likewise I trust that most potential users of BU_BFRD will similarly be lucky and not need full subdirectory backups. On this point it should help a little if you ensure that the FIRST file on your disk (that follows immediately after the rootdirectory ends) is NOT a subdirecory but, preferably, some large, static and easily- replaced program e.g. CALAMUS.PRG or similar. Then if sectors near the top of the rootdirectory are damaged (by Hardware Faults), no subdirectory sectors will then be "nearby" on the disk and hopefully they'll stay undamaged. Of course, it cannot be emphasized enough that NONE of these "quick" options is a substitute for a "full" backup - but they DO save the day in situations where the FATS have been damaged but the files are intact. Good Luck, W. Alan B. Evans. July 1993.